BLUEPRINT

4 외부 통합 지점

제4장: 외부 통합 지점

본 장에서는 CAP 프로토콜과 외부 시스템의 통합 지점을 기술하고, 각 통합 지점의 역할 경계, 상호작용 방향 및 통신 프로토콜 요구사항을 명확히 한다. CAP 프로토콜은 독립적으로 운영되는 시스템이 아니며, iFay_Runtime, 단말 운영체제, 하드웨어 드라이버 및 Registration_Authority 등 외부 시스템과 협력하여 단말 제어 권한 관리를 공동으로 완수해야 한다. 이러한 통합 지점의 인터페이스 경계와 상호작용 방식을 이해하는 것은 시스템 통합자가 CAP 프로토콜을 올바르게 구현하기 위한 전제 조건이다.

4.1 iFay_Runtime과의 통합

iFay_Runtime은 Fay(iFay 또는 coFay)의 런타임 환경으로, Fay 인스턴스의 생명주기 관리와 스케줄링을 담당한다. CAP 프로토콜의 관점에서 iFay_Runtime은 제어권 요청의 발행자이다 — Fay가 단말 자원에 접근해야 할 때, iFay_Runtime이 대신 CAP 프로토콜 계층에 인가 검증 요청을 발행한다.

통합 역할:

제어권 요청 발행: iFay_Runtime은 Fay를 대표하여 Protocol_Engine에 인가 검증 요청을 제출하며, 요청에는 Fay의 신원 식별자, 대상 Terminal_Resource 및 인가 자격 증명(Authorization_Descriptor 또는 Trusted_Ticket)이 포함된다
Fay의 생명주기 관리: iFay_Runtime은 Fay 인스턴스의 시작, 일시 중지, 재개 및 종료를 담당한다. Fay 인스턴스가 종료될 때, iFay_Runtime은 Protocol_Engine에 해당 Fay가 보유한 모든 활성 Session의 해제를 통지한다
생존 감지 채널 유지: iFay_Runtime은 Fay와 단말 간의 장기 연결을 유지하고, 구성된 간격에 따라 애플리케이션 계층 하트비트 메시지를 전송하여 Liveness_Detection 메커니즘의 정상 운영을 지원한다
세션 상태 알림 수신: Protocol_Engine은 Session의 상태 변경(생성 성공, 인계 요청, 강제 종료 등)을 iFay_Runtime에 통지하고, iFay_Runtime이 해당 Fay 인스턴스에 전달한다

상호작용 방향: 양방향(Bidirectional)

iFay_Runtime은 CAP 프로토콜 계층에 요청을 발행하고(인가 검증, 세션 해제, 하트비트 전송), CAP 프로토콜 계층은 iFay_Runtime에 응답을 반환하고 알림을 푸시한다(검증 결과, 세션 상태 변경, 인계 요청).

통신 프로토콜 요구사항:

iFay_Runtime과 Protocol_Engine 간에는 메시지 기반 요청-응답 모드를 채택하며, 메시지 형식은 CAP 프로토콜 Schema 정의를 따른다
생존 감지 채널은 장기 연결을 지원해야 하며, 애플리케이션 계층 하트비트와 실시간 상태 푸시를 구현한다
통신 채널은 TLS 암호화를 지원하여 인가 자격 증명과 세션 정보의 전송 과정에서의 기밀성과 무결성을 보장해야 한다
메시지 직렬화 형식은 Schema 정의 파일(schema.json)과 일치해야 하며, 크로스 구현 상호운용성을 보장한다

4.2 단말 운영체제와의 통합

단말 운영체제는 Terminal_Resource의 관리자로, 단말의 소프트웨어 및 하드웨어 자원에 대한 통합 관리를 담당한다. CAP 프로토콜은 운영체제와의 통합을 통해 인가 검증 결과를 실제 자원 접근 제어로 변환한다 — 운영체제는 Protocol_Engine의 지시에 따라 Fay의 특정 자원에 대한 접근을 허용하거나 거부한다.

통합 역할:

자원 접근 제어 실행: 운영체제는 Protocol_Engine이 하달한 접근 제어 지시에 따라 시스템 수준에서 Fay의 Terminal_Resource에 대한 접근을 허용하거나 차단한다. 여기에는 파일 시스템 접근 제어, 프로세스 권한 관리, 장치 접근 허가 등이 포함된다
자원 상태 보고: 운영체제는 Protocol_Engine에 Terminal_Resource의 현재 상태(가용, 점유, 불가용)를 보고하여 Protocol_Engine이 정확한 자원 배분 결정을 내릴 수 있게 한다
실행 환경 격리: 운영체제는 서로 다른 Fay의 작업에 대해 프로세스 수준 또는 샌드박스 수준의 격리를 제공하여 한 Fay의 작업이 다른 Fay 또는 인간 사용자의 자원 접근에 영향을 미치지 않도록 보장한다
자원 이벤트 전달: Terminal_Resource의 상태가 변경될 때(예: 하드웨어 분리, 소프트웨어 충돌), 운영체제는 이벤트 알림을 Protocol_Engine에 전달하여 해당하는 Session 종료 또는 자원 회수 프로세스를 트리거한다

상호작용 방향: 양방향(Bidirectional)

CAP 프로토콜 계층은 운영체제에 접근 제어 지시와 자원 조회 요청을 하달하고, 운영체제는 CAP 프로토콜 계층에 자원 상태를 보고하고 자원 이벤트를 전달한다.

통신 프로토콜 요구사항:

CAP 프로토콜 계층과 운영체제 간에는 로컬 프로세스 간 통신(IPC) 메커니즘을 채택하며, 구체적 방식은 운영체제 플랫폼에 따라 다르다(예: Unix Domain Socket, Named Pipe, D-Bus 등)
접근 제어 지시는 동기 호출 방식으로 실행되어 Protocol_Engine이 지시 실행 결과를 즉시 확인할 수 있도록 보장한다
자원 이벤트 알림은 비동기 푸시 방식을 채택하며, 운영체제가 자원 상태 변화 시 능동적으로 Protocol_Engine에 통지한다
통신 인터페이스는 운영체제 네이티브 보안 모델을 따라야 하며, 인가된 Protocol_Engine 프로세스만이 접근 제어 지시를 하달할 수 있도록 보장한다

4.3 하드웨어 드라이버와의 통합

하드웨어 드라이버는 하드웨어 유형 Terminal_Resource(카메라, 마이크, GPS 모듈, 저장 장치 등)의 접근 인터페이스이다. CAP 프로토콜은 하드웨어 드라이버와의 통합을 통해 하드웨어 자원에 대한 세밀한 제어권 관리를 구현한다. 하드웨어 드라이버는 CAP 프로토콜의 통합 체계에서 운영체제 아래에 위치하며, 하드웨어 자원의 하위 수준 접근 기능을 제공한다.

통합 역할:

하드웨어 자원 접근 인터페이스 제공: 하드웨어 드라이버는 CAP 프로토콜 계층에 하드웨어 자원의 능력 기술과 작업 인터페이스를 노출하여 Protocol_Engine이 하드웨어 자원이 지원하는 접근 모드(read, write, execute, configure)를 파악할 수 있게 한다
하드웨어 수준 접근 제어 실행: 하드웨어 드라이버는 Protocol_Engine이 운영체제를 경유하여 전달한 제어 지시에 따라 하드웨어 수준에서 접근 허가 또는 거부를 실행한다. 예를 들어, Fay의 카메라 활성화, 마이크 접근을 허용하거나 금지한다
하드웨어 상태 보고: 하드웨어 드라이버는 상위 계층에 하드웨어 장치의 연결 상태, 작동 상태 및 이상 정보를 보고하며, 이 정보는 최종적으로 Protocol_Engine에 전달되어 Session 관리 결정에 사용된다
하드웨어 자원의 배타적 제어 지원: 배타적 접근이 필요한 하드웨어 자원(예: 카메라의 비디오 스트림 출력)의 경우, 하드웨어 드라이버가 하위 수준에서 동일 시점에 하나의 제어자만 독점 사용할 수 있도록 보장한다

상호작용 방향: 단방향(Unidirectional) — CAP 프로토콜 계층 → 하드웨어 드라이버

CAP 프로토콜 계층은 운영체제를 통해 하드웨어 드라이버에 제어 지시를 하달하고, 하드웨어 드라이버의 상태 정보는 운영체제의 장치 관리 계층을 통해 상위로 전달된다. CAP 프로토콜 계층은 하드웨어 드라이버와 직접 통신 채널을 구축하지 않으며, 운영체제를 중개자로 하여 간접적으로 상호작용한다. 하드웨어 상태의 보고 경로는: 하드웨어 드라이버 → 운영체제 → Protocol_Engine이며, 운영체제 통합 지점(4.2)의 일부에 해당한다.

통신 프로토콜 요구사항:

CAP 프로토콜 계층은 하드웨어 드라이버와 직접 통신하지 않으며, 모든 상호작용은 운영체제의 장치 관리 인터페이스(예: DeviceIoControl, ioctl, sysfs 등)를 통해 간접적으로 완료된다
하드웨어 자원의 능력 기술은 통일된 자원 기술 형식을 따라야 하며, Protocol_Engine이 서로 다른 유형의 하드웨어 자원을 일관된 방식으로 관리할 수 있도록 한다
하드웨어 드라이버는 운영체제가 제공하는 표준 장치 접근 제어 인터페이스를 지원하여 CAP 프로토콜의 접근 제어 지시가 하드웨어 수준에서 적용될 수 있도록 보장한다
고민감 하드웨어 자원(예: 카메라, 마이크)의 경우, 하드웨어 드라이버는 하드웨어 수준의 접근 잠금 메커니즘을 지원하여 운영체제 수준의 접근 제어를 우회하는 것을 방지한다

4.4 Registration_Authority와의 통합

Registration_Authority(등록 기관)는 CAP 프로토콜 신뢰 인프라의 핵심 구성 요소로, 단말 하드웨어, 소프트웨어 및 운영체제의 등록 관리와 단말에 대한 검증 키(Verification_Key) 배포를 담당한다. 단말이 Registration_Authority를 통해 획득하는 Verification_Key는 오프라인 인가 검증의 신뢰 앵커이다 — 합법적인 Verification_Key가 없으면 단말은 Authorization_Descriptor의 디지털 서명을 검증할 수 없다.

통합 역할:

단말 등록: 단말 장치(하드웨어, 운영체제 및 클라이언트 소프트웨어 포함)는 Registration_Authority를 통해 등록을 완료하고, 고유한 단말 식별자와 초기 구성 정보를 획득한다
Verification_Key 배포: Registration_Authority는 등록된 단말에 Verification_Key를 배포하며, 단말은 이 키를 사용하여 Authorization_Descriptor의 디지털 서명을 검증한다. 키 배포 과정은 반드시 보안 채널을 통해 완료되어야 하며, 키의 변조나 탈취를 방지한다
키 업데이트 및 교체: Verification_Key를 업데이트해야 할 때(예: 키 만료, 발급자 변경), Registration_Authority는 단말에 새로운 키를 푸시하고 키 교체 과정에서의 원활한 전환을 조율한다
등록 상태 관리: Registration_Authority는 단말의 등록 상태를 유지하며, 등록, 일시 중지 및 등록 해제를 포함한다. 단말의 등록 상태는 Verification_Key 업데이트 수신 및 CAP 프로토콜의 인가 검증 프로세스 참여 가능 여부에 영향을 미친다

상호작용 방향: 단방향(Unidirectional) — Registration_Authority → 단말

Registration_Authority는 단말에 Verification_Key와 등록 정보를 배포하며, 단말은 수동적으로 수신한다. 단말은 Registration_Authority에 인가 검증 요청을 발행하거나 운영 상태를 보고하지 않는다 — 단말의 인가 검증은 완전히 로컬에서 완료되며(이미 배포된 Verification_Key를 사용), Registration_Authority와 실시간 통신을 유지할 필요가 없다. 단말이 Registration_Authority에 발행하는 등록 요청은 일회성 초기화 프로세스에 해당하며, CAP 프로토콜 런타임의 상시 상호작용에 해당하지 않는다.

통신 프로토콜 요구사항:

Registration_Authority와 단말 간의 통신은 반드시 보안 채널(예: TLS/mTLS)을 통해 완료되어야 하며, Verification_Key의 전송 과정에서의 기밀성과 무결성을 보장한다
키 배포 프로토콜은 오프라인 사전 설치와 온라인 업데이트의 두 가지 모드를 지원해야 한다: 단말 출하 시 초기 Verification_Key를 사전 설치하고, 이후 온라인 채널을 통해 키 업데이트를 수신한다
키 업데이트 메시지에는 버전 번호와 발효 시간이 포함되어야 하며, 신구 키의 원활한 전환 기간을 지원하여 키 교체로 인한 인가 검증 중단을 방지한다
Registration_Authority는 키 배포의 확인 메커니즘을 제공하여 단말이 새로운 Verification_Key를 성공적으로 수신하고 저장했는지 확인해야 한다

4.5 통합 지점 상호작용 방향 및 통신 프로토콜 총괄

아래 표는 CAP 프로토콜과 4개 외부 시스템의 통합 지점 정보를 요약하며, 상호작용 방향과 통신 프로토콜 요구사항을 포함한다:

통합 지점	외부 시스템	상호작용 방향	통신 프로토콜 요구사항
4.1	iFay_Runtime	양방향(Bidirectional)	메시지 기반 요청-응답 모드; 장기 연결 지원(생존 감지); TLS 암호화; 메시지 형식은 CAP Schema 정의를 따름
4.2	단말 운영체제	양방향(Bidirectional)	로컬 프로세스 간 통신(IPC); 동기 호출 + 비동기 이벤트 푸시; 운영체제 네이티브 보안 모델 준수
4.3	하드웨어 드라이버	단방향(CAP → 하드웨어 드라이버)	운영체제 장치 관리 인터페이스를 통한 간접 통신; 통일된 자원 기술 형식; 하드웨어 수준 접근 잠금 지원
4.4	Registration_Authority	단방향(RA → 단말)	TLS/mTLS 보안 채널; 오프라인 사전 설치 및 온라인 업데이트 지원; 키 버전 관리 및 원활한 교체

상호작용 방향 설명:

양방향(Bidirectional): CAP 프로토콜 계층과 외부 시스템 간에 양방향 요청-응답 또는 이벤트 알림 상호작용이 존재하며, 양측 모두 능동적으로 통신을 개시할 수 있다
단방향(Unidirectional): 정보 흐름이 한 쪽에서 다른 쪽으로만 흐른다. 4.3에서 CAP 프로토콜 계층은 운영체제를 통해 하드웨어 드라이버에 지시를 하달하고(직접 통신하지 않음); 4.4에서 Registration_Authority는 단말에 키와 등록 정보를 배포한다(단말은 수동적으로 수신)

통신 프로토콜 설계 원칙:

보안성: 인가 자격 증명과 키 전송에 관련된 모든 통신 채널은 반드시 암호화되어야 하며, 중간자 공격과 정보 유출을 방지한다
플랫폼 적응성: 운영체제 및 하드웨어 드라이버와의 통합은 플랫폼 네이티브 인터페이스를 채택하여 서로 다른 운영체제에서의 호환성을 보장한다
상호운용성: iFay_Runtime 및 Registration_Authority와의 통합은 표준화된 메시지 형식(CAP Schema 기반)을 채택하여 서로 다른 구현 간의 상호운용성을 보장한다
내결함성: 통신 프로토콜은 재시도 및 저하 메커니즘을 지원하여 통신 중단 시에도 CAP 프로토콜 핵심 기능(특히 오프라인 인가 검증)의 정상 운영에 영향을 미치지 않도록 한다